`:top

`!Root-Nameserver`! (kurz: `*Root-Server`*) sind `F33f`_`[Server`:/page/entry.mu`zim=wikipedia_de_all_nopic_2026-01.zim|entry_path=Server]`_`f zur `F33f`_`[Namensauflösung`:/page/entry.mu`zim=wikipedia_de_all_nopic_2026-01.zim|entry_path=Namensauflösung]`_`f an der Wurzel (`*Root`*) des `F33f`_`[Domain Name Systems`:/page/entry.mu`zim=wikipedia_de_all_nopic_2026-01.zim|entry_path=Domain_Name_System]`_`f im Internet. Die Root-`F33f`_`[Zone`:/page/entry.mu`zim=wikipedia_de_all_nopic_2026-01.zim|entry_path=Zone_(DNS)]`_`f umfasst Namen und `F33f`_`[IP-Adressen`:/page/entry.mu`zim=wikipedia_de_all_nopic_2026-01.zim|entry_path=IP-Adresse]`_`f der Nameserver aller `F33f`_`[Top-Level-Domains`:/page/entry.mu`zim=wikipedia_de_all_nopic_2026-01.zim|entry_path=Top-Level-Domain]`_`f (TLD).

Praktisch jeder ans `F33f`_`[Internet`:/page/entry.mu`zim=wikipedia_de_all_nopic_2026-01.zim|entry_path=Internet]`_`f angeschlossene Rechner bekommt einen `F33f`_`[Nameserver`:/page/entry.mu`zim=wikipedia_de_all_nopic_2026-01.zim|entry_path=Domain_Name_System]`_`f zugewiesen, der Namen wie „de.wikipedia.org“ in technische Nummern (IP-Adressen) übersetzen kann. Hat der Nameserver keine Information zur angefragten TLD (in diesem Fall „org“), wendet er sich an die Root-Server. Dort werden die für „org“ zuständigen Nameserver abgefragt. Bei den org-Nameservern wiederum werden die für „wikipedia.org“ verantwortlichen Nameserver erfragt und dort schließlich die IP-Adresse von „de.wikipedia.org“. Damit der Nameserver diese Kette nicht jedes Mal neu durchlaufen muss, `F33f`_`[speichert`:/page/entry.mu`zim=wikipedia_de_all_nopic_2026-01.zim|entry_path=DNS-Caching]`_`f er die Antworten für eine gewisse Zeit.

Root-Server werden von verschiedenen Institutionen betrieben. Die `F33f`_`[Internet Corporation for Assigned Names and Numbers`:/page/entry.mu`zim=wikipedia_de_all_nopic_2026-01.zim|entry_path=Internet_Corporation_for_Assigned_Names_and_Numbers]`_`f (ICANN) koordiniert den Betrieb.

>>Contents

• `F0af`_`[Auflistung`#auflistung]`_`f

• `F0af`_`[Aufsicht`#aufsicht]`_`f

• `F0af`_`[Ausfallsicherheit und Angriffe`#ausfallsicherheit-und-angriffe]`_`f

• `F0af`_`[Alternative DNS-Roots`#alternative-dns-roots]`_`f

• `F0af`_`[Aus der Geschichte`#aus-der-geschichte]`_`f

• `F0af`_`[Weblinks`#weblinks]`_`f

• `F0af`_`[Einzelnachweise`#einzelnachweise]`_`f

-─

>>Auflistung

Es gibt 13 Root-Nameserver, die fortlaufend nach dem Schema <Buchstabe>.root-servers.net benannt sind. Jeder Root-Nameserver ist unter einer `F33f`_`[IPv4`:/page/entry.mu`zim=wikipedia_de_all_nopic_2026-01.zim|entry_path=IPv4]`_`f-Adresse und einer `F33f`_`[IPv6`:/page/entry.mu`zim=wikipedia_de_all_nopic_2026-01.zim|entry_path=IPv6]`_`f-Adresse erreichbar. Alle Root-Nameserver setzen `F33f`_`[Anycast`:/page/entry.mu`zim=wikipedia_de_all_nopic_2026-01.zim|entry_path=Anycast]`_`f zur `F33f`_`[Lastverteilung`:/page/entry.mu`zim=wikipedia_de_all_nopic_2026-01.zim|entry_path=Lastverteilung_(Informatik)]`_`f ein, sodass die 13 Adressen gleichzeitig von verschiedenen Orten der Welt bedient werden. Stand August 2024 gibt es zusammen mit allen Anycast-Instanzen 1865 Root-Server.`:cite-ref-1[`F5bf`_`[1`#cite-note-1]`_`f]

`t

| Buchstabe | Alter Name | IPv4-Adresse | IPv6-Adresse | Betreiber |

|---|---|---|---|---|

| A | ns.internic.net | 198.41.0.4 | 2001:503:ba3e::2:30 | VeriSign |

| B | ns1.isi.edu | 170.247.170.2 | 2801:1b8:10::b | USC -ISI |

| C | c.psi.net | 192.33.4.12 | 2001:500:2::c | Cogent Communications |

| D | terp.umd.edu | 199.7.91.13 | 2001:500:2d::d | University of Maryland |

| E | ns.nasa.gov | 192.203.230.10 | 2001:500:a8::e | NASA Ames Research Center |

| F | ns.isc.org | 192.5.5.241 | 2001:500:2f::f | ISC |

| G | ns.nic.ddn.mil | 192.112.36.4 | 2001:500:12::d0d | U.S. DoD NIC |

| H | aos.arl.army.mil | 198.97.190.53 | 2001:500:1::53 | US Army Research Lab |

| I | nic.nordu.net | 192.36.148.17 | 2001:7fe::53 | Netnod |

| J | - | 192.58.128.30 | 2001:503:c27::2:30 | VeriSign |

| K | - | 193.0.14.129 | 2001:7fd::1 | RIPE NCC |

| L | - | 199.7.83.42 | 2001:500:9f::42 | ICANN |

| M | - | 202.12.27.33 | 2001:dc3::35 | WIDE Project |

`t

>>Aufsicht

Historisch lag die Aufsicht über die Verwaltung der Root-Zone und weiterer `F33f`_`[IANA`:/page/entry.mu`zim=wikipedia_de_all_nopic_2026-01.zim|entry_path=Internet_Assigned_Numbers_Authority]`_`f-Aufgaben bei der US-Regierung. Die Telekommunikationsbehörde NTIA, die dem `F33f`_`[US-Handelsministerium`:/page/entry.mu`zim=wikipedia_de_all_nopic_2026-01.zim|entry_path=Handelsministerium_der_Vereinigten_Staaten]`_`f unterstellt ist, beauftragte die ICANN mit den IANA-Aufgaben. Kritiker erachteten das Mitspracherecht der US-Regierung als problematisch. Neben der vertraglichen Bindung wurde auch kritisiert, dass die ICANN als `F33f`_`[kalifornische`:/page/entry.mu`zim=wikipedia_de_all_nopic_2026-01.zim|entry_path=Kalifornien]`_`f Organisation dem Risiko einer politischen Einflussnahme ausgesetzt ist.`:cite-ref-2[`F5bf`_`[2`#cite-note-2]`_`f]

Seit 2016 trägt die ICANN die Verantwortung selbst, da die NTIA auf ihre Aufsichtsrolle verzichtet hat. Die ICANN gab die IANA-Aufgaben an ihre neu gegründete Tochterfirma Public Technical Identifiers (PTI) ab, um technische und strategische Funktionen organisatorisch zu trennen.

Änderungsanträge an der Root-Zone werden zunächst von der PTI entgegengenommen, auf technische und formale Korrektheit geprüft`:cite-ref-3[`F5bf`_`[3`#cite-note-3]`_`f] und anschließend an `F33f`_`[Verisign`:/page/entry.mu`zim=wikipedia_de_all_nopic_2026-01.zim|entry_path=Verisign]`_`f weitergeleitet. Verisign führt die Änderung durch, signiert die geänderte Root-Zone mit `F33f`_`[DNSSEC`:/page/entry.mu`zim=wikipedia_de_all_nopic_2026-01.zim|entry_path=Domain_Name_System_Security_Extensions]`_`f und verteilt die neue `F33f`_`[Zonendatei`:/page/entry.mu`zim=wikipedia_de_all_nopic_2026-01.zim|entry_path=Zonendatei]`_`f über dedizierte Verteilungs-Server an die Root-Server-Betreiber.`:cite-ref-4[`F5bf`_`[4`#cite-note-4]`_`f] Bis 2002 erfolgte die Verteilung direkt über `F33f`_`[Zonentransfers`:/page/entry.mu`zim=wikipedia_de_all_nopic_2026-01.zim|entry_path=Zonentransfer]`_`f vom A-Root-Server, was aus Sicherheitsgründen aufgegeben wurde.`:cite-ref-5[`F5bf`_`[5`#cite-note-5]`_`f]

>>Ausfallsicherheit und Angriffe

Die Root-Server bearbeiten eine sehr große Anzahl von Anfragen, ein erheblicher Teil davon verursacht durch fehlerhafte Software oder Netzwerkkonfiguration.`:cite-ref-6[`F5bf`_`[6`#cite-note-6]`_`f] Eine Filterung auf DNS-Ebene findet nicht statt, da dies aufgrund der Einfachheit einer DNS-Anfrage mehr Ressourcen aufwenden würde, als alle Anfragen zu beantworten.

Gemäß RFC 2870`:cite-ref-7[`F5bf`_`[7`#cite-note-7]`_`f] muss jeder Root-Server mit dem dreifachen Peak des am stärksten belasteten Root-Servers umgehen können. Das bedeutet, dass ein Root-Server im Normalbetrieb nur maximal ein Drittel seiner Kapazität ausnutzen darf. Fallen zwei Drittel der Root-Server aus, soll das noch betriebsfähige Drittel die Anfragen beantworten können.

Der Angriff mit der größten Wirkung auf die Root-Server fand am 21. Oktober 2002 statt. Ein `F33f`_`[DDoS`:/page/entry.mu`zim=wikipedia_de_all_nopic_2026-01.zim|entry_path=Distributed_Denial_of_Service]`_`f erfolgte 75 Minuten lang mit zusammen 900 MBit/s (1,8 Mpkts/s) auf alle 13 Root-Server. Alle Root-Server blieben zwar lauffähig, da die vorgeschalteten Firewalls den Angriffsverkehr verwarfen, allerdings waren etwa neun Root-Server durch die überfluteten Leitungen schlecht bis gar nicht erreichbar. Root-Server-Lookups wurden dadurch deutlich verzögert, durch das Caching gab es jedoch kaum Störungen bei den Anwendern. Ausgelöst durch den DDoS-Angriff wurde die Umsetzung von Anycast beschleunigt.

Ein weiterer Angriff fand am 15. Februar 2006 statt, einige Tage, nachdem die Nameserver einer von der ICANN nicht genannten Top-Level-Domain angegriffen worden waren.`:cite-ref-8[`F5bf`_`[8`#cite-note-8]`_`f] Dieser DDoS-Angriff wurde als `F33f`_`[DNS Amplification Attack`:/page/entry.mu`zim=wikipedia_de_all_nopic_2026-01.zim|entry_path=DNS_Amplification_Attack]`_`f durchgeführt, wodurch sich das aufgekommene Datenvolumen vervielfachte. Zwei der lediglich drei angegriffenen Root-Server waren 15 Minuten lang nicht erreichbar.

Am 6. Februar 2007 fand ein weiterer DDoS-Angriff auf die Root-Server und gleichzeitig auf einige TLD-Nameserver statt. Zwei Root-Server waren nicht erreichbar.`:cite-ref-9[`F5bf`_`[9`#cite-note-9]`_`f]

>>Alternative DNS-Roots

Neben den ICANN-Root-Servern gibt es alternative Root-Server-Netzwerke, die aus politischen oder kommerziellen Gründen entstanden sind. In der Regel bezwecken die Anbieter eine Autonomie gegenüber dem etablierten Root-Server-Netzwerk. Vereinzelt werden Domains unterhalb eigener Top-Level-Domains verkauft. Diese TLDs sind ausschließlich Nutzern des jeweiligen Anbieters zugänglich, da sie in der ICANN-Root-Zone nicht vorhanden sind. Durch die Einführung `F33f`_`[neuer Top-Level-Domains`:/page/entry.mu`zim=wikipedia_de_all_nopic_2026-01.zim|entry_path=Neue_Top-Level-Domains]`_`f besteht das Risiko von Kollisionen für die Nutzer alternativer Root-Server.

Aktive Anbieter:

• `F33f`_`[OpenNIC`:/page/entry.mu`zim=wikipedia_de_all_nopic_2026-01.zim|entry_path=OpenNIC]`_`f ist ein DNS-Root, der nach eigener Aussage von Freiwilligen ohne kommerzielle Interessen betrieben wird. Neben den Top-Level-Domains der ICANN löst OpenNIC auch einige eigene TLDs auf.

• Yeti DNS ist ein offenes `F33f`_`[Testbed`:/page/entry.mu`zim=wikipedia_de_all_nopic_2026-01.zim|entry_path=Testbed]`_`f zur Durchführung technischer Experimente an einem DNS-Root.`:cite-ref-10[`F5bf`_`[10`#cite-note-10]`_`f]`:cite-ref-11[`F5bf`_`[11`#cite-note-11]`_`f]

Ehemalige Anbieter:

• Bis 2019 existierte das `F33f`_`[Open Root Server Network`:/page/entry.mu`zim=wikipedia_de_all_nopic_2026-01.zim|entry_path=Open_Root_Server_Network]`_`f (ORSN), um den Einfluss der ICANN auf das Domain Name System zu senken.

• Public-Root war ein Anbieter, der sich als unabhängige Non-Profit-Alternative verstand. Seit 2011 wird die Website nicht mehr gepflegt und die DNS-Server sind außer Betrieb.

• Cesidian ROOT

• `F33f`_`[Open Root Server Confederation`:/page/entry.mu`zim=wikipedia_de_all_nopic_2026-01.zim|entry_path=Open_Root_Server_Confederation]`_`f

• Enhanced Domain Name Service (eDNS) bot bis zur Außerbetriebnahme 1998 die zusätzlichen Top-Level-Domains .biz, .corp, .fam, .k12, .npo, .per und .web an.

>>Aus der Geschichte

Historisch wurde die Anzahl der Server auf 13 beschränkt:`:cite-ref-12[`F5bf`_`[12`#cite-note-12]`_`f]`:cite-ref-13[`F5bf`_`[13`#cite-note-13]`_`f]

• Die maximale Größe (`F33f`_`[MTU`:/page/entry.mu`zim=wikipedia_de_all_nopic_2026-01.zim|entry_path=Maximum_Transmission_Unit]`_`f) eines Datenpaketes, welches das Internet zuverlässig passieren kann, wurde konservativ angenommen (brutto 576 Byte, abzüglich Verwaltungsdaten).

• Da aus Leistungsgründen das verbindungslose `F33f`_`[UDP`:/page/entry.mu`zim=wikipedia_de_all_nopic_2026-01.zim|entry_path=User_Datagram_Protocol]`_`f das bevorzugte Transport-Protokoll für DNS-Anfragen ist, musste die Antwort in nur einem Paket untergebracht werden.

• So wurde die maximale Größe einer DNS-Antwort auf 512 Byte festgelegt, damit konnten Informationen über maximal 13 Server übermittelt werden.

• Aktuelle Software kann mit größeren DNS-Datenpaketen umgehen.

Bevor `F33f`_`[Anycast`:/page/entry.mu`zim=wikipedia_de_all_nopic_2026-01.zim|entry_path=Anycast]`_`f eingesetzt wurde, befanden sich 10 der 13 Root-Server in den `F33f`_`[USA`:/page/entry.mu`zim=wikipedia_de_all_nopic_2026-01.zim|entry_path=Vereinigte_Staaten]`_`f. Dies wurde hinsichtlich der Ausfallsicherheit kritisiert, da eine geografische Zentrierung dem Dezentralisierungsgedanken des Internets entgegenläuft.

>>Weblinks

• root-servers.org

• iana.org – Root Zone Management

• `*Internet in Deutschland bekommt eigenen DNS-Rootserver`*. heise online

• `F33f`_`[Daniel Karrenberg`:/page/entry.mu`zim=wikipedia_de_all_nopic_2026-01.zim|entry_path=Daniel_Karrenberg]`_`f: `*The Internet Domain Name System Explained for Non-Experts`*. internetsociety.org (englisch).

>>Einzelnachweise

`:cite-note-1`!1.`! `F0af`_`[↑`#cite-ref-1]`_`f `*Root Server Technical Operations Association.`* Abgerufen am 14. Mai 2024.

`:cite-note-2`!2.`! `F0af`_`[↑`#cite-ref-2]`_`f `*ICANN Strategy Committee`*. ICANNWatch

`:cite-note-3`!3.`! `F0af`_`[↑`#cite-ref-3]`_`f `*Root Zone Change Request Process`*. `F33f`_`[IANA`:/page/entry.mu`zim=wikipedia_de_all_nopic_2026-01.zim|entry_path=Internet_Assigned_Numbers_Authority]`_`f.

`:cite-note-4`!4.`! `F0af`_`[↑`#cite-ref-4]`_`f iana.org (PDF)

`:cite-note-5`!5.`! `F0af`_`[↑`#cite-ref-5]`_`f gao.gov (PDF; 0,5 MB) S. 6.

`:cite-note-6`!6.`! `F0af`_`[↑`#cite-ref-6]`_`f News Release. University of California, San Diego, External Relations: News & Information

`:cite-note-7`!7.`! `F0af`_`[↑`#cite-ref-7]`_`f `*`F33f`_`[RFC`:/page/entry.mu`zim=wikipedia_de_all_nopic_2026-01.zim|entry_path=Request_for_Comments]`_`f: 2870`* – `*Root Name Server Operational Requirements`*. Juni 2000 (englisch).

`:cite-note-8`!8.`! `F0af`_`[↑`#cite-ref-8]`_`f icann.org (PDF)

`:cite-note-9`!9.`! `F0af`_`[↑`#cite-ref-9]`_`f `*Großangriff auf DNS-Rootserver`*. heise Netze

`:cite-note-10`!10.`! `F0af`_`[↑`#cite-ref-10]`_`f `*`F33f`_`[RFC`:/page/entry.mu`zim=wikipedia_de_all_nopic_2026-01.zim|entry_path=Request_for_Comments]`_`f: 8483`* – `*Yeti DNS Testbed`*. Oktober 2018 (englisch).

`:cite-note-11`!11.`! `F0af`_`[↑`#cite-ref-11]`_`f yeti-dns.org

`:cite-note-12`!12.`! `F0af`_`[↑`#cite-ref-12]`_`f `*dns extension mechanism for enum`*. `F33f`_`[IETF`:/page/entry.mu`zim=wikipedia_de_all_nopic_2026-01.zim|entry_path=Internet_Engineering_Task_Force]`_`f (englisch)

`:cite-note-13`!13.`! `F0af`_`[↑`#cite-ref-13]`_`f `*`F33f`_`[RFC`:/page/entry.mu`zim=wikipedia_de_all_nopic_2026-01.zim|entry_path=Request_for_Comments]`_`f: 3226`* – `*DNSSEC, IPv6 requirements`*. (englisch).

`c`F0af`_`[↑ Back to top`#top]`_`f`a